View SN260Q_6838305.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

march 2009 rev 4 1/47 1 sn260 zigbee? 802.15.4 network processor features integrated 2.4ghz, i eee 802.15.4-compliant transceiver: ? robust rx filtering allows co-existence with ieee 802.11g an d bluetooth devices ? ?99 dbm rx sensitivity (1% per, 20-byte packet) ? +2.5 dbm nominal output power ? increased radio performance mode (boost mode) gives ?100 dbm sensitivity and +4.5 dbm transmit power ? integrated vco and loop filter ? secondary tx-only rf port for applications requiring external pa. integrated ieee 802 .15.4 phy and mac dedicated peripherals and integrated memory ember zigbee?-compliant stack running on the dedicated network processor controlled by the host using the emberznet? serial protocol (ezsp) ? standard spi or uart interfaces allow for connection to a variety of host microcontrollers non-intrusive debug interface (sif) integrated hardware and software support for insight? development environment provides integrated rc oscillator for low power operation three sleep modes: ? processor idle (automatic) ? deep sleep?1.0a ? power down?1.0a watchdog timer and power-on-reset circuitry integrated aes encryption accelerator integrated 1.8v voltage regulator www.st.com
contents sn260 2/47 contents 1 abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2 references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 general description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4 pin assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5 top-level functional descrip tion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6 functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1 receive (rx) path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1.1 rx baseband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.1.2 rssi and cca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2 transmit (tx) path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.1 tx baseband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.2 tx_active signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.3 integrated mac module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.4 packet trace interface (pti) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.5 16-bit microprocessor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.6 embedded memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.6.1 simulated eeprom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.6.2 flash information area (fia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.7 encryption accelerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.8 nreset signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.9 reset detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.10 power-on-reset (por) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.11 clock sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.11.1 high-frequency crystal oscillator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.11.2 internal rc oscillator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.12 random number generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.13 watchdog timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.14 sleep timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
sn260 contents 3/47 6.15 power management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7 spi protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1 physical interface configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2 spi transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.2.1 command section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.2.2 wait section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.2.3 response section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.2.4 asynchronous signaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.2.5 spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2.6 waking the sn260 from sleep . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2.7 error conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.3 spi protocol timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.4 data format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.5 spi byte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.5.1 primary spi bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.5.2 special response bytes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.6 powering on, power cycling, and rebooting . . . . . . . . . . . . . . . . . . . . . . . 29 7.6.1 bootloading the sn260 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.6.2 unexpected resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.7 transaction examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.7.1 spi protocol version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.7.2 emberznet serial protocol frame ? version command . . . . . . . . . . . . . 31 7.7.3 sn260 reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.7.4 three-part transaction: wake, get version, stack status callback . . . . 33 8 uart gateway protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 9 sif module programming and debug interface . . . . . . . . . . . . . . . . . . 37 10 typical application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 11 package mechanical data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 12 ordering information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 13 electrical characteristi cs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
contents sn260 4/47 13.1 absolute maximum ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 13.2 recommended operating conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 13.3 environmental characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 13.4 dc electrical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 13.5 digital i/o specificati ons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 13.6 rf electrical characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 13.6.1 receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 13.6.2 transmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 13.6.3 synthesizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 14 revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
sn260 abbreviations and acronyms 5/47 1 abbreviations and acronyms table 1. abbreviations and acronyms acronym/abbreviation meaning acr adjacent channel rejection aes advanced encryption standard cbc-mac cipher block chaining?message authentication code cca clear channel assessment ccm counter with cbc-mac mode for aes encryption ccm* improved counter with cbc-mac mode for aes encryption csma carrier sense multiple access ctr counter mode eeprom electrically erasable programmable read only memory esd electro static discharge esr equivalent series resistance ffd full function device (zigbee) fia flash information area gpio general purpose i/o (pins) hf high frequency (24 mhz) i 2 c inter-integrated circuit bus ide integrated development environment if intermediate frequency ip3 third order intermodulation product isr interrupt service routine kb kilobyte kbps kilobits/second lf low frequency lna low noise amplifier lqi link quality indicator mac medium access control msl moisture sensitivity level msps mega samples per second o-qpsk offset-quadrature phase shift keying pa power amplifier per packet error rate phy physical layer pll phase-locked loop por power-on-reset psd power spectral density psrr power supply rejection ratio pti packet trace interface
references sn260 6/47 2 references zigbee specification (www.zigbee.org; zigbee document 053474) zigbee-pro stack profile (www.zigbee.org; zigbee document 074855) zigbee stack profile (www.zigbee.org; zigbee document 064321) bluetooth core specification v2.1 (www.bluetooth.com/bluetooth/technology/building/specifications/default.htm) ieee 802.15.4-2003 (standards.ieee.org/getieee802/download/802.15.4-2003.pdf) ieee 802.11g (standards.ieee.org/getieee802/download/802.11g-2003.pdf) ember em260 reference design (ember.com/products_documentation.html) pwm pulse width modulation rohs restriction of hazardous substances rssi receive signal strength indicator sfd start frame delimiter sif serial interface spi serial peripheral interface uart universal asynchronous receiver/transmitter vco voltage controlled oscillator vdd voltage supply table 1. abbreviations and acronyms (continued) acronym/abbreviation meaning
sn260 general description 7/47 3 general description the sn260 integrates a 2.4ghz , ieee 802.15.4-complia nt transceiver with a 16-bit network processor (xap2 b core) to run emberznet?, the embe r zigbee-compliant network stack. the sn260 exposes access to the emberznet api across a standard spi module or a uart module, allowing application development on a host platform. this means that the sn260 can be viewed as a zigbee peripheral connected over a serial interface. the xap2b microprocessor is a power-optimized core integrated in the sn260. it contains integrated flash and ram memory along with an optimized peripheral set to enhance the operation of the network stack. the transceiver utilizes an efficient arch itecture that exceeds the dynamic range requirements imposed by the ieee 802.15.4-2003 standard by over 15db. the integrated receive channel filtering allows for co-existence with other communication standards in the 2.4ghz spectrum such as ieee 802.11g and bluetooth. the integrated regulator, vco, loop filter, and power amplifier keep the external component count low. an optional high- performance radio mode (boost mode) is software selectable to boost dynamic range by a further 3db. the sn260 contains embedded flash and integrated ram for program and data storage. by employing an effective wear-leveling algorithm, the stack optimizes the lifetime of the embedded flash, and affords th e application the ability to co nfigure stack a nd application tokens within the sn260. to maintain the strict timi ng requirements imposed by zi gbee and the i eee 802.15.4-2003 standard, the sn260 integrates a number of mac functions into the hardware. the mac hardware handles automatic ack transmission and reception, automatic backoff delay, and clear channel assessment for transmission, as well as automatic filtering of received packets. in addition, the sn260 allows for true mac level debugging by integrating the packet trace interface. an integrated voltage regulator, power-on-reset circuitry, sleep timer, and low-power sleep modes are available. the deep sleep and power down modes draw less than 1 a, allowing products to achieve long battery life. finally, the sn260 utilizes the non-intrusive sif module for powerful software debugging and programming of the network processor. target applications for the sn260 include: building automation and control home automation and control home entertainment control asset tracking the sn260 can only be purchased with the embe rznet stack. this technical datasheet describes the sn260 features available to customers using it with the emberznet stack.
pin assignment sn260 8/47 4 pin assignment figure 1. sn260 pin assignment for spi protocol sn260
sn260 pin assignment 9/47 figure 2. sn260 pin assignment for uart protocol sn260 table 2. pin descriptions pin # signal direction description 1 vdd_vco power 1.8v vco supply 2 rf_p i/o differential (with rf_n) receiver input/transmitter output 3 rf_n i/o differential (with rf_p) receiver input/transmitter output 4 vdd_rf power 1.8v rf supply (lna and pa) 5 rf_tx_alt_p o differential (with rf_tx_ alt_n) transmitter output (optional) 6 rf_tx_alt_n o differential (with rf_tx_ alt_p) transmitter output (optional) 7 vdd_if power 1.8v if supply (mixers and filters) 8 bias_r i bias setting resistor 9 vdd_padsa power analog pad supply (1.8v) 10 tx_active o logic-level control for external rx/tx switch the sn260 baseband controls tx_active and drives it high (1.8v) when in tx mode. (refer to ta bl e 1 5 and section tx_active signal.) 11 nreset i active low chip reset (internal pull-up) 12 vreg_out power regulator output (1.8v) 13 vdd_pads power pads supply (2.1 ? 3.6v) 14 vdd_core power 1.8v digital core supply
pin assignment sn260 10/47 15 nssel_int i spi slave select interrup t (from host to sn260) this signal must be con nected to nssel (pin 21) ncts i uart clear to send (enables sn260 transmission) when using the uart interface, this signal should be left unconnected if not used. 16 n.c. i when using the spi interface, th is signal is left not connected. nrts o uart request to send (enables host transmission) when using the uart interface, this signal should be left unconnected if not used. 17 mosi i spi data, master out / sl ave in (from host to sn260) n.c. i when using the uart interface, this signal is left not connected. 18 miso o spi data, master in / slave out (from sn260 to host) n.c. i when using the uart interface, this signal is left not connected. 19 vdd_pads power pads supply (2.1 ? 3.6v) 20 sclk i spi clock (from host to sn260) n.c. i when using the uart interface, this signal is left not connected. 21 nssel i spi slave select (from host to sn260) n.c. i when using the uart interface, this signal is left not connected. 22 pti_en o frame signal of packet trace interface (pti) 23 pti_data o data signal of packet trace interface (pti) 24 vdd_pads power pads supply (2.1 ? 3.6v) 25 n.c. i when using the spi interface, th is signal is left not connected. txd o uart transmitted data (from sn260 to host) 26 nhost_int o host interrupt signal (from sn260 to host) rxd i uart received data (from host to sn260) 27 sif_clk i programming and debug interface, clock (internal pull down) 28 sif_miso o programming and debug interface, master in / slave out 29 sif_mosi i programming and debug interface, master out / slave in (external pull-down re-quired to guarantee state in deep sleep mode) 30 nsif_load i/o programming and debug interface, load strobe (open collector with internal pull up) 31 gnd power ground supply 32 vdd_flash power 1.8v flash memory supply 33 sdbg o spare debug signal 34 link_activity o link and activity signal 35 nwake i wake interrupt signal (from host to sn260) n.c. i when using the uart interface, this signal is left not connected. 36 vdd_core power 1.8v digital core supply 37 vdd_synth_pre power 1.8v synthesizer and pre-scalar supply table 2. pin descriptions (continued) pin # signal direction description
sn260 pin assignment 11/47 38 oscb i/o 24mhz crystal oscillator or left open for when using an external clock input on osca 39 osca i/o 24mhz crystal oscillator or external clock input 40 vdd_24mhz power 1.8v high-frequency oscillator supply 41 gnd ground ground supply pad in the bottom center of the package forms pin 41 (see the sn260 reference design for pcb considerations) table 2. pin descriptions (continued) pin # signal direction description
top-level functional description sn260 12/47 5 top-level functional description figure 3 shows a detailed block diagram of the sn260. figure 3. sn260 block diagram the radio receiver is a low-if, super-heterodyne receiver. it utilizes differential signal paths to minimize noise interference, and its architecture has been chosen to optimize co- existence with other devices within the 2.4ghz band (namely, ieee 802.11g an d bluetooth). after amplification and mixing, the signal is filtered and combined prior to being sampled by an adc. the digital receiver implements a coherent demodulator to generate a chip stream for the hardware-based mac. in addition, the digital receiver contains the analog radio calibration routines and control of the gain within the receiver path. the radio transmitter utilizes an efficient archit ecture in which the da ta stream directly modulates the vco. an integrated pa boosts the output power. the calibration of the tx path as well as the output power is controlled by digital logic. if the sn260 is to be used with an external pa, the tx_active signal should be used to control the timing of the external switching logic. the integrated 4.8 ghz vco and loop filter minimize off-chip circuitry. only a 24mhz crystal with its loading capacitors is required to properly establish the pll reference signal. the mac interfaces the data memory to the rx and tx baseband modules. the mac provides hardware-based ieee 802.15.4 packet-level filtering. it supplies an accurate symbol time base that minimizes the synchronization effort of the software stack and meets the protocol timing requirements. in addition, it provides timer and synchronization assistance for th e ieee 802.15.4 csma-ca algorithm.
sn260 top-level functional description 13/47 the sn260 integrates hardware support for a packet trace module, which allows robust packet-based debug. this element is a critical component of insight desktop, the ember software ide, providing advanced network de bug capability when coup led with the insight adapter. the sn260 integrates a 16-bit xap2b microprocessor developed by cambridge consultants ltd. this power-efficient, industry-proven core provides the appropriate level of processing power to meet the needs of the ember zigbee-compliant stack, emberznet. in addition, the sif module provides a non-intrusive programming and debug interface allowing for real-time application debugging. the sn260 exposes the ember serial api over either a spi or uart interface, which allows application development to occur on a host platform of choice. the spi interface uses the four standard spi signals plus two addi tional signals, nhost_int and nwake, which provide an easy-to-use handshake mechanism between the host and the sn260. the uart interface uses the two standard uart signals and also supports either standard rts/cts or xon/xoff flow control. the integrated voltage regulator generates a regulated 1.8v reference voltage from an unregulated supply voltage. this voltage is decoupled and routed externally to supply the 1.8v to the core logic. in addition, an integrated por module allows for the proper cold start of the sn260. the sn260 contains one high-frequency (24 mhz) crysta l oscillator and, for low-power operation, a second low-frequency internal 10 khz oscillator. the sn260 contains two power domains. the always-powered high voltage supply is used for powering the gpio pads and critical chip fu nctions. the rest of the chip is powered by a regulated low voltage supply which can be disabled during deep sleep to reduce the power consumption.
functional description sn260 14/47 6 functional description the sn260 connects to the host platform through either a standard spi interface or a standard uart interface. the emberznet serial protocol (ezsp) has been defined to allow an application to be written on a host platform of choice. therefore, the sn260 comes with a license to emberznet, the ember zigbee-com pliant software stack. the following brief description of the hardware modules provides the necessary background on the operation of the sn260. for more information, contact your local st sales representative. 6.1 receive (rx) path the sn260 rx path spans the analog and digita l domains. the rx architecture is based on a low-if, super-heterodyne receiver. it utilizes differential signal paths to minimize noise interference. the input rf signal is mixed down to the if frequency of 4mhz by i and q mixers. the output of the mixers is filtered and combined prior to being sampled by a 12msps adc. the rx filtering within the rx path has been designed to optimize the co- existence of the sn260 with other 2.4ghz transceivers, such as the ieee 802.11g and bluetooth. 6.1.1 rx baseband the sn260 rx baseband (within the digital domain) implements a coherent demodulator for optimal performance. the base band demodulates th e o-qpsk signal at the chip level and synchronizes with the ieee 802.15.4-2003 preamble. an automatic gain control (agc) module adjusts the analog if gain continuous ly (every ? symbol) until the preamble is detected. once the packet preamble is detected, the if gain is fixed during the packet reception. the baseband de-spreads the demodulated data into 4-bit symbols. these symbols are buffered and passed to the hardware-based mac module for filtering. in addition, the rx baseband provides the calibration and control interface to the analog rx modules, including the lna, rx baseband fi lter, and modulation modules. the emberznet software includes calibration algorithms which use this interface to reduce the effects of process and temperature variation. 6.1.2 rssi and cca the sn260 calculates the rssi over an 8-symbol period as well as at the end of a received packet. it utilizes the rx gain settings and the output level of the adc within its algorithm. the linear range of rssi is specified to be 40db over all temperatures. at room temperature, the linear range is approximately 60db (-90 dbm to -30dbm). the sn260 rx baseban d provides support for the i eee 802.15.4-2003 required cca methods summarized in ta bl e 3 . modes 1, 2, and 3 are defined by the 802.15.4-2003 standard; mode 0 is a proprietary mode.
sn260 functional description 15/47 the emberznet software stack sets the cca mode, and it is not configurable by the application layer. for software versions begi nning with emberznet 2.5.4, cca mode 1 is used, and a busy channel is reported if the rssi exceeds its threshold. for software versions prior to 2.5.4, the cca mode was set to 0. at rx input powers higher than ?25 dbm, there is some compression in the receive chain where the gain is not properly adjusted. in the worst case, this has resulted in packet loss of up to 0.1%. this packet loss can be seen in range testing measurements when nodes are closely positioned and transmitting at high power or when receiving from test equipment. there is no damage to th e sn260 from this problem. this issue will rarely occur in the field as zigbee nodes will be spaced far enough apart. if nodes are close en ough for it to occur in the field, the mac and networking software treat the packet as not having been received and therefore the mac level and network level retries resolve the problem without needing to notify the upper level application. 6.2 transmit (tx) path the sn260 transmitter utilizes bot h analog circuitry and digita l logic to produce the o-qpsk modulated signal. the area-efficient tx architecture directly modulates the spread symbols prior to transmission. the differential signal paths increase noise immunity and provide a common interface for the external balun. 6.2.1 tx baseband the sn260 tx baseband (within the digital domain) performs the spreading of the 4-bit symbol into its ieee 802.15.4- 2003-defined 32-chip i and q sequence. in addition, it provides the interface for software to perform the calibration of the tx module in order to reduce process, temperature, and voltage variations. 6.2.2 tx_active signal even though the sn260 provides an output power suitable for most zigbee applications, some applications will require an external po wer amplifier (pa). due to the timing requirements of ieee 802.15.4-20 03, the sn250 provides a signa l, tx_active, to be used for external pa power management and rf switching logic. when in tx, the tx baseband drives tx_active high (as described in ta b l e 1 5 ). when in rx, the tx_active signal is low. if an external pa is not required, then the tx_active signal should be connected to gnd through a 100k ohm resistor, as shown in the application circuit in figure 14 . the tx_active signal can only source 1ma of cu rrent, and it is based upon the 1.8v signal swing. if the pa control logic requires greater current or voltage potential, then tx_active should be buffered externally to the sn260. table 3. cca mode behavior cca mode mode behavior 0 clear channel reports busy medium if either carrier sense or rssi exceeds their thresholds. 1 clear channel reports busy medium if rssi exceeds its threshold. 2 clear channel reports busy medium if carrier sense exceeds its threshold. 3 clear channel reports busy medium if bot h rssi and carrier sense exceed their thresholds.
functional description sn260 16/47 6.3 integrated mac module the sn260 integrates critical portions of the ieee 802.15. 4-2003 mac requirements in hardware. this allows the sn260 to provide greater bandwidth to application and network operations. in addition, the hardware acts as a first-line filter for non-intended packets. the sn260 mac utilizes a dma interface to ra m memory to further reduce the overall microcontroller interaction when tr ansmitting or receiving packets. when a packet is ready for transmission, the software configures the tx mac dma by indicating the packet buffer ram location. the mac waits for the backoff period, then transitions the baseband to tx mode and performs channel assessment. when the channel is clear, the mac reads data from the ram buffer, calculates the crc, and provides 4-bit symbols to the baseband. when the final byte has been read and sent to the baseband, the crc remainder is read and transmitted. the mac resides in rx mode most of the time, and different format and address filters keep non-intended packets from using excessive ram buffers, as well as preventing the sn260 cpu from being interrupted. when the reception of a packet begins, the mac reads 4-bit symbols from the baseband and calculates the crc. it assembles the received data for storage in a ram buffer. a rx mac dma provides direct access to the ram memory. once the packet has been received, additional data is appended to the end of the packet in the ram buffer space. the appended data provides statistical information on the packet for the software stack. the primary features of the mac are: crc generation, appending, and checking hardware timers and interrupts to achieve the mac symbol timing automatic preamble, and sfd pre-pended to a tx packet address recognition and packet filtering on received packets automatic acknowledgement transmission automatic transmission of packets from memory automatic transmission after backoff time if channel is clear (cca) automatic acknowledgement checking time stamping of received and transmitted messages attaching packet information to received packets (lqi, rssi, gain, time stamp, and packet status) ieee 802.15.4-2003 timing and slotted/unslotted timing 6.4 packet trace interface (pti) the sn260 integrates a true phy-level pti for effective network-level debugging. this two- signal interface monitors all the phy tx and rx packets (in a non-intrusive manner) between the mac and baseband modules. it is an asynchronous 500 kbps interface and cannot be used to inject packets into the phy/mac interface. the two signals from the sn260 are the frame signal (pti_en) and the data signal (pti_data). the pti is supported by insight desktop.
sn260 functional description 17/47 6.5 16-bit microprocessor the sn260 integrates the xap2b microprocessor developed by cambridge consultants ltd., making it a true network processo r solution. the xap2b is a 16-bit harvard architecture processor with separate program and data address spaces. the word width is 16 bits for both the program and data sides. the standard xap2 microp rocessor and accompanying softw are tools have been enhanced to create the xap2b microprocessor used in the sn260. the xap2b adds data-side byte addressing support to the xap2 allowing for more productive usage of ram and optimized code. the xap2b clock speed is 12mhz. when used wit h the emberznet stack, firmware may be loaded into flash memory using the sif mechanism (described in section 9: sif module programming and debug interface ) or over the air or by a serial link using a built-in bootloader1 in a reserved area of the flash. alternatively, firmware may be loaded via the sif interface with the assist ance of ram-based utility rout ines also loaded via sif. 6.6 embedded memory the sn260 contains embedded flash and ram memory for firmware storage and execution. in addition it pa rtitions a portion of the flas h for simulated eeprom and token storage. 6.6.1 simulated eeprom the protocol stack reserves a section of flash memory to provide simulated eeprom storage area for stack and customer tokens. the flash cell has been qualified for a data retention time of >100 years at room temperature and is rated to have a guaranteed 1,000 write/erase cycles. because the flash cells ar e qualified for up to 1,000 write cycles, the simulated eeprom implements an effective wear-leveling algorithm which effectively extends the number of write cycles for individual tokens. the number of set-token operations is finite due to the write cycle limitation of the flash. it is not possible to guarantee an exact number of set-token operations because the life of the simulated eeprom depends on which tokens are written and how often. the sn260 stores non-volatile information necessary for network operation as well as 8 tokens available to the host. the majority of internal tokens are only written when the sn260 performs a network join or leave operation. as a simple estimate of possible set- token operations, consider an sn260 in a stable network (no joins or leaves) not sending any messages where the host uses only one of the 8-byte tokens available to it. under this scenario, a very rough estimate results in approximately 330,000 possible set-token operations. the number of possible set-token calls, though, depends on which tokens are being set, so the ratios of set-token calls for each token plays a large factor. a very rough estimate for the total number of times an app token can be set is approximately 320,000. these estimates would typically increase if the sn260 is kept closer to room temperature, since the 1,000 guaranteed write cycles of the flash is for across temperature.
functional description sn260 18/47 6.6.2 flash information area (fia) the sn260 also includes a separate 1024-byte fia that can be used for storage of data during manufacturing, including serial numbers and calibration values. programming of this special flash page can only be enabled using the sif interface to prevent accidental corruption or erasure. the emberznet stack reserves a small portion of this space for its own use and in addition makes eight manufacturing tokens available to the application. 6.7 encryption accelerator the sn260 contains a hardware aes encryption engine that is attached to the cpu using a memory-mapped interface. the cbc-mac and ctr modes are implemented in hardware, and ccm* is implemented in software. the first two modes are described in the ieee 802.15.4-2003 specification. ccm* is described in the zigbee specification (zigbee document 053474). the emberznet stack implements a security api for applications that require security at the application level. 6.8 nreset signal when the asynchronous external reset signal, nreset (pin 13) , is driven low for a time greater than 200ns, the sn260 resets to its default state. an integrated glitch filter prevents noise from causing an inadvertent reset to occur. if the sn260 is to be placed in a noisy environment, an external lc filter or supervisory reset circuit is recommended to guarantee the integrity of the reset signal. when nreset asserts, all sn260 registers retu rn to their reset state. in addition, the sn260 consumes 1.5ma (typical) of current when held in reset. 6.9 reset detection the sn260 contains multiple reset sources. the reset event is logged into the reset source register, which lets the cpu determine the cause of the last reset. the following reset causes are detected: power-on-reset watchdog pc rollover software reset core power dip
sn260 functional description 19/47 6.10 power-on-reset (por) each voltage domain (1.8v digital core su pply vdd_core and pads supply vdd_pads) has a power-on-reset (por) cell. the vdd_pads por cell holds the always-powered high-voltage domain in reset until the following conditions have been met: the high-voltage pads supply vdd_pads voltage rises above a threshold. the internal rc clock starts and generates three clock pulses. the 1.8v por cell holds the main digital core in reset until the regulator output voltage rises above a threshold. additionally, the digital domain counts 1,024 clock edges on the 24mhz crystal before releasing the reset to the main digital core. ta bl e 4 lists the features of the sn260 por circuitry. 6.11 clock sources the sn260 integrates two oscillators: a high-f requency 24-mhz crystal oscillator and a low- frequency internal 10 -khz rc oscillator. 6.11.1 high-frequency crystal oscillator the integrated high-freque ncy crystal oscillator requires an external 24mhz crystal with an accuracy of 40ppm. based upon the applicat ion bill of materials a nd current consumption requirements, the external crystal can cover a range of esr requirements. for a lower esr, the cost of the crystal increases but the over all current consumption decreases. likewise, for higher esr, the cost decreases but the current consumption increases. therefore, the designer can choose a crystal to fit the needs of the application. ta bl e 5 lists the specifications for the high-frequency crystal. table 4. por specifications parameter min. typ. max. unit vdd_pads por release 1.00 1.20 1.40 v vdd_pads por assert 0.50 0.60 0.70 v 1.8v por release 1.35 1.50 1.65 v 1.8v por hysteres is 0.08 0.10 0.12 v table 5. high-frequency crystal specifications parameter test conditions min. typ. max. unit frequency 24 mhz duty cycle 40 60 % phase noise from 1 khz to 100 khz - 120 dbc/hz accuracy initial, temperature, and aging - 40 + 40 ppm
functional description sn260 20/47 6.11.2 internal rc oscillator the sn260 has a low-power, low-frequency rc os cillator that runs all the time. its nominal frequency is 10 khz. the rc oscillator has a coarse analog trim c ontrol, which is firs t adjusted to get the frequency as close to 10 khz as possible. this raw clock is used by the chip management block. it is also divided down to 1khz using a variable divider to allow software to accurately calibrate it. this calibrated clock is used by the sleep timer. timekeeping accuracy depends on temperature fluctuations the chip is exposed to, power supply impedance, and the calibration interval, but in general it will be better than 150 ppm (including crystal error of 40 ppm). ta bl e 6 lists the specifications of the rc oscillator. 6.12 random number generator the sn260 allows for the generation of random numbers by exposing a randomly generated bit from the rx adc. analog noise current is passed through the rx path, sampled by the receive adc, and stored in a register. the value contained in this register could be used to seed a software-generated ra ndom number. the emberznet stack utilizes these random numbers to seed the random mac backoff and encryption key generators. crystal esr load capacitance of 10pf 100 crystal esr load capacitance of 18pf 60 start-up time to stable clock (max. bias) 1ms start-up time to stable clock (optimum bias) 2ms current consumption good crystal: 20 esr, 10pf load 0.2 0.3 ma current consumption worst-case crystals (60 , 18pf or 100 , 10pf) 0.5 ma current consumption at maximum bias 1 ma table 5. high-frequency crystal specifications (continued) parameter test conditions min. typ. max. unit table 6. rc oscillator specifications parameter test conditions min. typ. max. unit frequency 10 khz analog trim steps 1 khz frequency variation with supply for a voltage drop from 3.6v to 3.1v or 2.6v to 2.1v 0.75 1.5 %
sn260 functional description 21/47 6.13 watchdog timer the sn260 contains an internal watchdog timer clocked from the intern al oscillator. if the timer reaches its time-out valu e of approximately 2 seconds, it will reset the sn260. this reset signal cannot be routed externally to the host. the sn260 firmware will periodically restart the watchdog timer while the firmware is running normally. the host cannot effect or configure the watchdog timer. 6.14 sleep timer the 16-bit sleep timer is contained in the always-powered digital block. the clock source for the sleep timer is a calibrated 1khz clock. the frequency is slowed down with a 2 n prescaler to generate a final timer resolution of 1ms. with a 1ms tick and a 16-bit timer, the timer wraps about every 65.5 seconds. the emberznet stack appropriately handles timer wraps allowing the host to orde r a theoretical maximum sle ep delay of 4 million seconds. 6.15 power management the sn260 supports four different power modes: active, idle, deep sleep, and power down. active mode is the normal, operating state of the sn260. while in idle mode, code execution halts until any interrupt occurs. all modules of the sn260 including the radio continue to operate normally. the emberznet stack automatically invokes idle as appropriate. deep sleep mode and power down mode both power off most of the sn260, including the radio, and leave only the critical chip functions powered. the internal regulator is disabled and vreg_out is turned off. all output signals are maintained in a frozen state. upon waking from deep sleep or power down mode, the internal regulator is re-enabled. deep sleep and power down result in the same sleep current consumption. the two sleep modes differ as follows: the sn260 can wake on both an internal timer and an external signal from deep sleep mode; power down mode can only wake on an external signal.
spi protocol sn260 22/47 7 spi protocol the sn260 low level protocol centers on the spi interface for communication with a pair of gpio for handshake signaling. the sn260 looks like a hardware peripheral. the sn260 is the slave device and all transactions are initiated by the host (the master). the sn260 supports a reasonably high data rate. 7.1 physical interface configuration the sn260 supports both spi slave mode 0 (clock is idle low, sample on rising edge) and spi slave mode 3 (clock is idle high, sample on rising edge) at a maximum spi clock rate of 5mhz, as illustrated in figure 4 . note: the convention for the waveforms in this document is to show mode 0. figure 4. spi transfer format, mode 0 and mode 3 the nhost_int signal and the nwake signal are bo th active low. the host must supply a pull-up resistor on the nhost_int signal to prevent errant interruptions during undefined events such as the sn260 resetting. the sn2 60 supplies an internal pull-up on the nwake signal to prevent errant interruptions during undefined events such as the host resetting. 7.2 spi transaction the basic sn260 spi transaction is half-duplex to ensure proper framing and to give the sn260 adequate response time. the basic transaction, as shown in figure 5 , is composed of three sections: command, wait, and response. the transaction can be considered analogous to a function call. the command section is the function call, and the response section is the return value. figure 5. general timing di agram for a spi transaction
sn260 spi protocol 23/47 7.2.1 command section the host begins the transaction by asserting the slave select and then sending a command to the sn260. this command can be of any length from 2 to 136 bytes and must not begin with 0xff . during the command section, the sn260 will respond with only 0xff . the host should ignore data on miso during the command section. once the host has completed transmission of the entire message, the transaction moves to the wait section. 7.2.2 wait section the wait section is a period of time during which the sn260 may be processing the command or performing other operations. note that this section can be any length of time up to 200 milliseconds. because of the variable size of the wait section, an interrupt-driven or polling-driven method is sugges ted for clocking the spi as opposed to a dma method. since the sn260 can require up to 200 millisecon ds to respond, as long as the host keeps slave select active, the host can perform other tasks while waiting for a response. to determine when a response is ready, use one of two methods: clock the spi until the sn260 transmits a byte other than 0xff . interrupt on the falling edge of nhost_int. the first method, clocking the spi, is reco mmended due to simplicity in implementing. during the wait section, the sn260 will transmit only 0xff and will ignore all incoming data until the response is ready. when the sn260 transmits a byte other than 0xff , the transaction has officially moved into the response section. therefore, the host can poll for a response by continuing to clock the spi by transmitting 0xff and waiting for the sn260 to transmit a byte other than 0xff . the sn260 will also indicate that a response is ready by asserting the nhost_int signal. the falling edge of nhost_int is the indication that a response is ready. once the nhost_int si gnal asserts, nhost_int will return to idle after the host begins to clock data. 7.2.3 response section when the sn260 transmits a byte other than 0xff , the transaction has officially moved into the response section. the data format is the same format used in the command section. the response can be of any length from 2 to 13 6 bytes and will not begin with 0xff . depending on the actual response, the length of the response is known from the first or second byte and this length should be used by the host to clock out exactly the correct number of bytes. once all bytes have been clocked, it is allowable for the host to de-assert chip select. since the host is in control of clocking the spi, there are no acks or similar signals needed back from the host because the sn260 will assu me the host could accept the bytes being clocked on the spi. after every transaction, the host must hold the slave select high for a minimum of 1ms. this timing requirement is called the inter-command spacing and is necessary to allow the sn260 to process a command and become ready to accept a new command. 7.2.4 asynchronous signaling when the sn260 has data to send to the host , it will assert the nhost_int signal. the nhost_int signal is designed to be an edge-triggered signal as opposed to a level- triggered signal; therefore, the falling edge of nhost_int is the true indicator of data availability. the host th en has the responsibility to initiate a transaction to ask the sn260 for its output. the host should initiate this transaction as soon as possible to prevent possible
spi protocol sn260 24/47 backup of data in the sn260. the sn2 60 will de-assert the nhos t_int signal after receiving a byte on the spi. due to inherent latency in the sn260, the timing of when the nhost_int signal returns to idle can vary between transactions. nhost_int will always return to idle for a minimum of 10s before asserting again. if the sn260 has more output available after the transaction has completed, the nh ost_int signal will assert again after slave select is de-asserted and the host must make another request. 7.2.5 spacing to ensure that the sn260 is always able to deal with incoming commands, a minimum inter- command spacing is defined at 1ms. after every transaction, the host must hold the slave select high for a minimum of 1ms. the host must respect the inter-command spacing requirement, or the sn260 will not have ti me to operate on th e command; additional commands could result in error conditions or undesired behavior. if the nhost_int signal is not already asserted, the host is allowed to use the wake handshake instead of the inter- command spacing to determine if the sn260 is ready to accept a command. 7.2.6 waking the sn260 from sleep waking up the sn260 involves a simple handshaking routine as illustrated in figure 6 . this handshaking ensures that the host will wait until the sn260 is fully awake and ready to accept commands from the host. if the sn260 is already awake when the handshake is performed (such as when the host resets and the sn260 is already operating), the handshake will proceed as descri bed below with no ill effects. note: a wake handshake cannot be performed if nhost_int is already asserted. figure 6. sn260 wake sequence waking the sn260 involves the following steps: 1. host asserts nwake. 2. sn260 interrupts on nwake and exits sleep. 3. sn260 performs all operations it needs to and will no t respond until it is ready to accept commands. 4. sn260 asserts nhost_int within 10ms of nwake asserting. if the sn260 does not assert nhost_int within 10ms of nwake, it is valid for the host to consider the sn260 unresponsive and to reset the sn260. 5. host detects nhost_int assertion. since the assertion of nhost_int indicates the sn260 can accept spi transactions, the host does not need to hold slave select high for the normally required minimum 1ms of inter-command spacing. 6. host de-asserts nwake after detecting nhost_int assertion. 7. sn260 will de-assert nhost_int wit hin 25 s of nwake de-asserting. 8. after 25s, any change on nhost_int will be an indication of a normal asynchronous (callback) event.
sn260 spi protocol 25/47 7.2.7 error conditions if two or more different error co nditions occur back to back, on ly the first error condition will be reported to the host (if it is possible to report the error). the following are error conditions that might occur with the sn260. unsupported spi command if the spi byte of the command is unsup ported, the sn260 will drop the incoming command and respond with the unsupported spi command error response. this error means the spi byte is unsupported by the current mode the sn260 is in. bootloader frames can only be used with the bootloader and ezsp frames can only be used with the ezsp. oversized payload frame if the transaction includes a payload frame, the length byte cannot be a value greater than 133. if the sn260 detects a length byte greater than 133, it will drop the incoming command and abort th e entire transaction . the sn260 will then assert nhost_int after slave select returns to idle to inform the host through an error code in the response section what has happened. not only is the command in the problematic transaction dropped by the sn260, but the next command is also dropped, because it is responded to with the oversized payload frame error response. aborted transaction an aborted transaction is any transaction where slave select returns to idle prematurely and the spi protocol dropped the transaction. the most common reason for slave select returning to idle prematurely is the host unexpectedly resetting. if a transaction is aborted, the sn260 will assert nhost_int to inform the host through an error code in the response section what has happened. when a transaction is aborted, not only does the command in the problematic transaction get dropped by the sn260, but the next command also gets dropped since it is responded to with the aborted transactio n error response. missing frame terminator every command and response must be terminated with the frame terminator byte. the sn260 will drop any command that is missing the frame terminator. the sn260 will then immediately provide the missing frame terminator error response. long transaction a long transaction error occurs when the host clocks too many bytes. as long as the inter-command spacing requirement is met, this error condition should not cause a problem, since the sn260 will send only 0xff outside of the response section as well as ignore incoming bytes outside of the command section. unresponsive unresponsive can mean the sn260 is not powered, not fully booted yet, incorrectly connected to the host, or busy performing other tasks. the host must wait the maximum length of the wait section before it can consider the sn260 unresponsive to the command section. this maximum length is 200 millis econds, measured from the end of the last byte sent in the command section. if the sn260 ever fails to respond during the wait section, it is valid for the host to consider the sn260 unresponsive and to reset the sn260. additionally, if nhos t_int does not assert within 10ms of nwake asserting during the wake handshake, the host can consider the sn260 unresponsive and reset the sn260.
spi protocol sn260 26/47 7.3 spi protocol timing figure 7 illustrates all critical timing paramet ers in the spi protocol. these timing parameters are a result of the sn260?s internal operation and both constrain host behavior and characterize sn260 operation. the parameters shown are discussed elsewhere in this document. note that figure 7 is not drawn to scale, but is provided to illust rate where the parameters are measured. figure 7. spi protocol timing waveform ta bl e 7 lists the timing parameters of the spi pr otocol. these parameters are illustrated in figure 7 . 7.4 data format the data format, also referred to as a command , is the same for both the command section and the response section. the data format of the spi protocol is straightforward, as illustrated in figure 8 . table 7. spi protocol timing parameters parameter description min. typ. max. unit t1 (a) wake handshake, while 260 is awake 133 150 s t1 (b) wake handshake, while 260 is asleep 7.3 10 ms t2 wake handshake finish 1.1 1.2 25 s t3 reset pulse width 8 s t4 (a) startup time, entering application 250 1500 ms t4 (b) startup time, entering bootloader 2.5 7.5 s t5 nhost_int de-asserting after command 13 35 75 s t6 clock rate 200 ns t7 wait section 25 755 200000 s t8 nhost_int de-asserting after response 20 130 800 s t9 nhost_int asserting after transaction 25 70 800 s t10 inter-command spacing 1 ms
sn260 spi protocol 27/47 figure 8. spi protocol data format the total length of a command must not exceed 136 bytes. all commands must begin with the spi byte . some commands are only two bytes?that is, they contain the spi byte and frame terminator only. the length byte is only included if there is information in the payload frame and the length byte defines the length of just the payload frame. therefore, if a command includes a payload frame, the length byte can have a value from 2 through 133 and the overall command size will be 5 through 136 bytes. the spi byte can be a specific value indicating if there is a payload frame or not, and if there is a payload frame, then the length byte can be expected. the error byte is used by the error responses to provide additional information about the error and appears in place of the length byte. this additional information is described in the following sections. the payload frame contains the data needed for operating emberznet. the ezsp frame and its format are explained in the ezsp reference guide (120-3009-000). the payload frame may also contain the data needed for operating the bootloader, which is called a bootloader frame. refer to the emberznet application developer?s guide (120-4028-000) for more information on the bootloader. the frame terminator is a special control byte used to mark the end of a command. the frame terminator byte is defined as 0xa7 and is appended to all commands and responses immediately after the final data byte. the purpose of the frame terminator is to provide a known byte the spi protocol can use to detect a corrupt command. for example, if the sn260 resets during the response sectio n, the host will still clock out the correct number of bytes. but when the host attempts to verify the value 0xa7 at the end of the response, it will see either the value 0x00 or 0xff and know that th e sn260 just reset and the corrupt response should be discarded. note: the length byte only specifies the length of the payload frame. it does not include the frame terminator. 7.5 spi byte ta bl e 8 lists the possible commands and their responses in the spi byte. table 8. spi commands & responses command value command response value response any any 0x00 sn260 reset occurred?this is never used in another response; it always indicates an sn260 reset. any any 0x01 oversized payload frame received?this is never used in another response; it always indicates an overflow occurred. any any 0x02 aborted transaction occurred?this is never used in another response; it always indicates an aborted transaction occurred.
spi protocol sn260 28/47 7.5.1 primary spi bytes there are four primary spi bytes: spi protocol version, spi status, bootloader frame and ezsp frame. spi protocol version [0x0a] : sending this command requests the spi protocol version number from the spi interface. the resp onse will always have bit 7 set and bit 6 cleared. in this current ve rsion, the response will be 0x 82, since the version number corresponding to this set of command-response values is version number 2. the version number can be a value from 1 to 63 (0x81?0xbf). spi status [0x0b] : sending this command asks for the sn260 status. the response status byte will always have the upper 2 bits se t. in this current vers ion, the status byte only has one status bit [0], which is set if the sn260 is alive and ready for commands. bootloader frame [0xfd] : this byte indicates that the current transaction is a bootloader transaction and ther e is more data to follow. this spi byte will cause the transaction to look like the full data format illustrated in figure 8. the byte immediately after this spi byte will be a length byte, and it is used to identi fy the length of the bootloader frame. refer to the emberznet application developer?s guide (120-4028- 000) for more information on the bootloader. if the spi byte is 0xfd, it means the minimum transaction size is four bytes. ezsp frame [0xfe] : this byte indicates that the current transaction is an ezsp transaction and there is more data to follow. this spi byte will cause the transaction to look like the full data format illustrated in figure 8. th e byte immediately after this spi byte will be a length byte, and it is used to identify the length of the ezsp frame. (the ezsp frame is defined in the ezsp reference guide, 120-3009-000.) if the spi byte is 0xfe, it means the minimum transaction size is five bytes any any 0x03 missing frame terminator?this is never used in another response; it always indicates a missing frame terminator in the command. any any 0x04 unsupported spi command?this is never used in another response; it always indicates an unsupported spi byte in the command. 0x00 ? 0x0f reserved [none] [none] 0x0a spi protocol version 0x81 ? 0xbf bit[7] is always set. bit[6] is always cleared. bit[5:0] is a number from 1?63. 0x0b spi status 0xc0 ? 0xc1 bit[7] is always set. bit[6] is always set. bit[0]?set if alive. 0xf0 ? 0xfc reserved [none] [none] 0xfd bootloader frame 0xfd bootloader frame 0xfe ezsp frame 0xfe ezsp frame 0xff invalid 0xff invalid table 8. spi commands & responses (continued) command value command response value response
sn260 spi protocol 29/47 7.5.2 special response bytes there are only five spi byte values, 0x00-0x04 , ever used as error codes (see ta bl e 9 ). when the error condit ion occurs, any command sent to the sn260 will be ignored and responded to with one of these codes. these special spi bytes must be trapped and dealt with. in addition, for each error condition the error byte (instead of the length byte) is also sent with the spi byte. 7.6 powering on, power cycling, and rebooting when the host powers on (or reboots), it cannot guarantee that the sn260 is awake and ready to receive commands. therefore, the host should always perform the wake sn260 handshake to guarantee that the sn260 is awake. if the sn260 resets, it needs to inform the host so that the host can reconfigure the stack if needed. when the sn260 resets, it will assert the nhos t_int signal, telling the host that it has data. the host should reques t data from the sn260 as usual. the sn 260 will ignore whatever command is sent to it and respond only with two bytes. the first byte will always be 0x00 and the second byte will be t he reset type as defined by emberresettype . this specialty spi byte is never used in anot her response spi byte. if the host sees 0x00 from the sn260, it knows that the sn260 ha s been reset. the sn260 will de-assert the nhost_int signal shortly after receiving a byte on the spi and process all further commands in the usual manner. in addition to the host having control of the reset line of the sn260, the emberznet serial protocol also provides a mechanism for a software reboot. 7.6.1 bootloading the sn260 the spi protocol supports a payload frame called the bootloader frame for communicating with the sn260 when the sn260 is in bootloader mode. the sn260 can enter bootload mode through either an ezsp command or holding one of two pins low while the sn260 exits reset. both the nwake pin and the pti_ data pin are capable of activating the bootloader while performing a standard sn260 reset procedure. assert nreset to hold the table 9. byte values used as error codes spi byte value error message error description error byte description 0x00 sn260 reset see section 7.6: powering on, power cycling, and rebooting . the reset type. refer to the api documentation discussing emberresettype. 0x01 oversized ezsp frame the command contained an ezsp frame with a length byte greater than 133. the sn260 was forced to drop the entire command. reserved 0x02 aborted transaction the transaction was not completed properly and the sn260 was forced to abort the transaction. reserved 0x03 missing frame terminator the command was missing the frame terminator. the sn260 was forced to drop the entire command. reserved 0x04 unsupported spi command the command contained an unsup-ported spi byte. the sn260 was forced to drop the entire command. reserved
spi protocol sn260 30/47 sn260 in reset. while nreset is asserted, assert (active lo w) either nwake or pti_data and then deassert nreset to b oot the sn260. do no t deassert nwake or pti_data until the sn260 asserts nhost_int, indicating that the sn260 has fully booted and is ready to accept data over the spi pr otocol. once nhost_int is asserted, nwake or pti_data way be deasserted. refer to the emberznet application developer?s guide (120-4028-000) for more information on the bootloader and the format of the bootloader frame. 7.6.2 unexpected resets the sn260 is designed to protect itself against undefined behavior due to unexpected resets. the protection is based on the state of slave select since the inter-command spacing mandates that slave select must return to idle. the sn260?s internal spi protocol uses slave select returning to idle as a trigger to re-initialize its spi protocol. by always re- initializing, the sn260 is protected against the host unexpectedly resetting or terminating a transaction. additionally, if slave select is ac tive when the sn260 powers on, the sn260 will ignore spi data until slave select returns to idle. by ignoring spi traffic until idle, the sn260 will not begin receiving in th e middle of a transaction. if the host resets, in most cases it should reset the sn260 as well so that both devices are once again in the same state: freshly booted. alternately, the host can attempt to recover from the reset by recovering its previous state and resynchronizing with the state of the sn260. if the sn260 resets during a transaction, the host can expect either a wait section timeout or a missing frame terminator indicating an invalid response. if the sn260 resets outside of a transaction, the host should proceed normally. 7.7 transaction examples this section contains the following transaction examples: spi protocol version emberznet serial protocol frame ? version command sn260 reset three-part transaction: wake, get version, stack status callback 7.7.1 spi protocol version figure 9. spi protocol version example
sn260 spi protocol 31/47 1. activate slave select (nssel). 2. transmit the command 0x0a - spi protocol version request. 3. transmit the frame terminator, 0xa7 . 4. wait for nhost_int to assert. 5. transmit and receive 0xff until a byte other than 0xff is received. 6. receive response 0x82 (a byte other than 0xff ), then receive the frame terminator, 0xa7 . 7. bit 7 is always set and bit 6 is always cl eared in the version response, so this is version 2. 8. de-activate slave select. 7.7.2 emberznet serial prot ocol frame ? version command figure 10. emberznet serial protoc ol frame - version command example 1. activate slave select (nssel). 2. transmit the appropriate command: ? 0xfe: spi byte indicating an ezsp frame ? 0x04: length byte showing the ezsp frame is 4 bytes long ? 0x00: ezsp sequence byte (note that this value should vary based upon previous sequence bytes) ? 0x00: ezsp frame control byte indicating a command with no sleeping ? 0x00: ezsp frame id byte indicating the version command ? 0x02: ezsp parameter for this command (desiredprotocolversion) ? 0xa7: frame terminator 3. wait for nhost_int to assert. 4. transmit and receive 0xff until a byte other than 0xff is received. 5. receive response 0xfe (a byte other than 0xff ) and read the next byte for a length. 6. stop transmitting after the number of bytes (length) is received plus the frame te r m i n a t o r. 7. decode the response: ? 0xfe: spi byte indicating an ezsp frame ? 0x07: length byte showing the ezsp frame is 7 bytes long ? 0x00: ezsp sequence byte (note that this value should vary based upon previous sequence bytes) ? 0x80: ezsp frame control byte indicating a response with no overflow ? 0x00: ezsp frame id byte indicating the version response ? 0x02: ezsp parameter for this response (protocolversion) ? 0x02: ezsp parameter for this response (stacktype)
spi protocol sn260 32/47 ? 0x11: ezsp parameter for this response (stackversion). note that this value may vary). ? 0x30: ezsp parameter for this response (stackversion). note that this value may vary). ? 0xa7: frame terminator 8. de-activate slave select. 7.7.3 sn260 reset figure 11. sn260 reset example 1. nreset toggles active low to reset the sn260. 2. nwake stays idle high between nreset and nhost_int indi cating the sn260 should continue with normal booting (do not enter the bootloader). 3. nhost_int asserts. 4. activate slave select (nssel). 5. transmit the command: ? 0xfe: spi byte indicating an ezsp frame ? 0x03: length byte showing the ezsp frame is 3 bytes long ? 0x00: ezsp sequence byte (note that this value should vary based upon previous sequence bytes) ? 0x00: ezsp frame control byte indicating a command with no sleeping ? 0x06: ezsp frame id byte indicating the callback command ? 0xa7: frame terminator 6. wait for nhost_int to assert. 7. transmit and receive 0xff until a byte other than 0xff is received. 8. receive response 0x00 (a byte other than 0xff ). 9. receive the error byte and decode ( 0x02 is enumerated as reset_poweron). 10. receive the frame terminator ( 0xa7 ). 11. response 0x00 indicates the sn260 has reset and the host should respond appropriately. 12. deactivate slave select. 13. since nhost_int does not assert again, there is no more data for the host.
sn260 spi protocol 33/47 7.7.4 three-part transaction: wake, get version, stack status callback figure 12. timing diagram of the three-part transaction 1. activate nwake and activate timeout timer. 2. sn260 wakes up (if not already) awake and enables communication. 3. nhost_int asserts, indicating the sn260 can accept commands. 4. host sees nhost_ int activation within 10ms an d deactivates nw ake and timeout timer. 5. nhost_int de-asserts immediately after nwake. 6. activate slave select. 7. transmit the command 0x0a - spi protocol version request. 8. transmit the frame terminator, 0xa7 . 9. wait for nhost_int to assert. 10. transmit and receive 0xff until a byte other than 0xff is received. 11. receive response 0x82 (a byte other than 0xff ), then receive the frame terminator, 0xa7 . 12. bit 7 is always set and bit 6 is always cl eared in the version response, so this is version 1. 13. deactivate slave select. 14. host begins timing the inter-command spacing of 1ms in preparation for sending the next command. 15. nhost_int asserts shortly after deactivating slave select, indicating a callback. 16. host sees nhost_int, but waits for the 1ms before responding. 17. activate slave select. 18. transmit the command: ? 0xfe: spi byte indicating an ezsp frame ? 0x03: length byte showing the ezsp frame is 3 bytes long ? 0x00: ezsp sequence byte (note that this value should vary based upon previous sequence bytes) ? 0x00: ezsp frame control byte indicating a command with no sleeping ? 0x06: ezsp frame id byte indicating the callback command ? 0xa7: frame terminator 19. wait for nhost_int to assert. 20. transmit and receive 0xff until a byte other than 0xff is received. 21. receive response 0xfe (a byte other than 0xff ), read the next byte for a length. 22. stop transmitting after the number of bytes (length) is received plus the frame te r m i n a t o r.
spi protocol sn260 34/47 23. decode the response: ? 0xfe: spi byte indicating an ezsp frame ? 0x04: length byte showing the ezsp frame is 3 bytes long ? 0x00: ezsp sequence byte (note that this value should vary based upon previous sequence bytes) ? 0x80: ezsp frame control byte indicating a response with no overflow ? 0x19: ezsp frame id byte indicating the stackstatushandler command ? 0x91: ezsp parameter for this response (emberstatus ember_network_down) ? 0xa7 ? frame terminator 24. deactivate slave select. 25. since nhost_int does not assert again, there is no more data for the host.
sn260 uart gateway protocol 35/47 8 uart gateway protocol the uart gateway protocol is designed for network gateway systems in which the host processor is running a full-scale operating system such as embedded linux or windows. the host sends emberznet serial protocol (ezsp) commands to the uart interface using ember?s asynchronous serial host (ash) protocol. the ezsp commands are the same as those used in the spi protocol, but the spi protocol is better suited for resource-constrained microcontroller hosts since ash uses considerably more host ram and program storage. ash implements error detection/recovery and tolerates latencies on multi-tasking hosts due to scheduling and i/o buffering. the ash protocol is described in detail in the uart gateway protocol reference, 120-3010-000. ember supplies ash host software in source form compatible with linux and windows. in most cases it will need only a fe w simple edits to adapt it to a particular host system. figure 13. uart interface signals the uart hardware interface uses the following sn260 signals: serial data: txd and rxd the ash protocol sends data in both directions, so both txd and rxd signals are required. an external pull-up resistor should be connected to txd to avoid data glitches while the sn260 is resetting. flow control: nrts and ncts (optional) ash uses hardware handshaking for flow control: nrts enables transmission from the host to the sn260, and ncts enables sn 260 transmissions to the host. if the host serial port cannot support rts/cts, xon/xoff flow control may be used instead. but, xon/xoff will deliver slightly lower performance. when using hardware flow control, the sn260?s nrts must be able to control host serial output. however, in many gateway systems, the host will not need to throttle transmission by the sn260. in those systems ncts may be left unconnected since it has an internal pull-down and will be continuously asserted. reset control: nreset the host must be able to reset the sn260 to run the ash protocol. the best way to do this is to use a host output connected to nreset. if this is not feasible, the host can send a special ash frame that requests the sn260 to reboot, but this method is less reliable than asserting nreset and is not recommended for normal use.
uart gateway protocol sn260 36/47 the uart signals follow the usual conventions: when idle, serial data is high (marking) the start bit is low (spacing), and the stop bit is high (marking) data bits are sent least-significant bit first, with positive (non-inverting) logic the flow control signals are asserted low note that commonly used eia transceivers invert these logic levels. ember supplies the uart gateway protocol software in two versions: one uses rtcs/cts flow control and the other uses xon/xoff. the uart is set up as follows for these versions: 115,200 bps for the rts/cts version 57,600 bps for the xon/xoff version no parity bit 8 data bits 1 stop bit the ash protocol has been tuned for optimal operation with the two configurations listed here. these configurations can be changed through manufacturing tokens, but doing so may result in a degradation of performance. to learn how to change the configuration, contact your local st sales representative.
sn260 sif module programming and debug interface 37/47 9 sif module programming and debug interface sif is a synchronous serial interface developed by cambridge consultants ltd. it is the primary programming and debug interface of the sn260. the sif module allows external devices to read and write memory-mapped registers in real-time without changing the functionality or timing of the xap2b core. see the applicat ion note pcb design with an sn260 (120-5047-000) for the pcb-level design details regarding the implementation of the sif interface. the sn260 pins involved in the sif interface: nsif_load sif_clk sif_mosi sif_miso nreset in addition, the vdd_pads and ground net are required for external voltage translation and buffering of the sif signals. the sif interface provides the following: pcb production test interface via virtual uart and an insight adapter programming and debug interface during emberznet application development in order to achieve the deep sleep currents specified in table 5, a pull-down resistor must be connected to the sif_mosi pin. in addition, ember recommends a pull-up resistor to be placed on the nsif_load pin in order to prevent noise from coupling onto the signal. both of these recommendations are documented within the sn260 reference designs. when developing application-specific manufacturing test procedures, ember recommends the designer refer to manufacturing test guidelines (120-5016-000). this document provides more detail regarding importance of designing the proper sif interface as well as timing of the sif.
typical application sn260 38/47 10 typical application figure 14 illustrates the typical application circuit for the sn260 using the spi protocol. this figure does not contain all decoupling capa citance required by the sn260. the balun provides the impedance transformation from the antenna to the sn260 for both tx and rx modes. the harmonic filter provides additional suppression of the second harmonic, which increases the margin over the fcc limit. th e 24mhz crystal with loading capacitors is required and provides the high frequency source for the sn260. the rc debounce filter (r4 and c7) is suggested to im prove the noise immunity of the nreset logic (pin 11). the sif (nsif_load, sif_mosi, sif_miso, and sif_clk), packet trace (pti_en and pti_data), and sdbg signals should be brought out test points or, if space permits to a 10- pin, dual row, 0.05-inch pitch header footprint. with a header populated, a direct connection to the insight adapter is possible which en hances the debug capabilit y of the sn260. for more information, visit www.st.com/mcu. figure 14. typical application circuit for spi protocol ta bl e 1 0 contains the bill of materials fo r the application circuit shown in figure 14 . sn260
sn260 typical application 39/47 table 10. bill of materials item quantity reference descrip tion manufacturer/part no. 1 1 c2 capacitor, 5pf, 50v, npo, 0402 2 2 c1,c3 capacitor, 0.5pf, 50v, npo, 0402 3 4 c4,c5 capacitor, 27pf, 50v, npo, 0402 4 1 c6 capacitor, 10f, 10v, tantalum, 3216 (size a) 5 1 c7 capacitor, 10pf, 5v, npo, 0402 6 1 l1 inductor, 2.7nh, +/- 5%, 0603, multi-layer murata lqg18hn2n7 7 2 l2 inductor, 3.3nh, +/- 5%, 0603, multi-layer murata lqg18hn3n3 8 1 r1 resistor, 169 k , 1%, 0402 9 1 r2 resistor, 100 k , 5% o402 10 1 r3 resistor, 3.3 k , 5% 0402 11 1 r4 resistor, 10 k , 5%, 0402 12 1 u1 sn260 single-chip zigbee/802.15.4 solution stmicroelectronics sn260 13 1 x1 crystal, 24.000mhz, 10 ppm tolerance, 25 ppm stability, 18pf, - 40c to + 85c ilsi ilcx08-jg5f18-24.000mhz 14 1 bln1 balun, ceramic tdk hhm1521
package mechanical data sn260 40/47 11 package mechanical data the sn260 package is a plastic 40-pin qfn that is 6mm x 6mm x 0.9mm. figure 15 illustrates the package drawing. figure 15. package drawing 12 ordering information use the following part numbers to order the sn260: SN260Qt reel, rohs SN260Q tray, rohs to order parts, contact your local stmicroelectronics sales representative, or go to our web site: www.st.com .
sn260 electrical characteristics 41/47 13 electrical characteristics 13.1 absolute maximum ratings ta bl e 1 1 lists the absolute maximum ratings for the sn260. 13.2 recommended op erating conditions ta bl e 1 2 lists the rated operating conditions of the sn260. table 11. absolute maximum ratings parameter test conditions min. max. unit regulator voltage (vdd_pads) - 0.3 3.6 v core voltage (vdd_24mhz, vdd_vco, vdd_rf, vdd_if, vdd_padsa, vdd_flash, vdd_synth_pre, vdd_core) - 0.3 2.0 v voltage on rf_p,n; rf_tx_alt_p,n - 0.3 3.6 v rf input power (for max. level for correct packet reception, see ta b l e 1 6 ) +15 dbm voltage on nssel_int, mosi, miso, sclk, nssel, pti_en, pti_data, nhost_int, sif_clk, sif_miso, si f_mosi, nsif_load, sdbg, link_activity, nwake, nreset, vreg_out - 0.3 vdd_pads+0.3 v voltage on tx_active, bias_r, osca, oscb - 0.3 vdd_core+0.3 v storage temperature - 40 + 140 c table 12. operating conditions parameter test conditions min. typ. max. unit regulator input voltage (vdd_pads) 2.1 3.6 v core input voltage (vdd_24mhz, vdd_vco, vdd_rf, vdd_if, vdd_padsa, vdd_flash, vdd_synth_pre, vdd_core) 1.7 1.8 1.9 v temperature range - 40 + 85 c
electrical characteristics sn260 42/47 13.3 environmental characteristics ta bl e 1 3 lists the environmental characteristics of the sn260. 13.4 dc electrical characteristics ta bl e 1 4 lists the dc electrical characteristics of the sn260. table 13. environmental characteristics parameter test conditions min. typ. max. unit esd (human body model) on any pin - 2 + 2 kv esd (charged device model) non-rf pins - 400 + 400 v esd (charged device model) rf pins - 225 + 225 v msl (moisture sensitivity level) msl3 table 14. dc characteristics parameter test conditions min. typ. max. unit regulator input voltage (vdd_pads) 2.1 3.6 v power supply range (vdd_core) regulator output or external input 1.7 1.8 1.9 v deep sleep current quiescent current, including internal rc oscillator at 25 c 1.0 a reset current quiescent curren t, nreset asserted typ at 25 c/3v max at 85 c/3.6v 1.5 2.0 ma rx current radio receiver, mac, and baseband (boost mode) 30.0 ma radio receiver, mac, and baseband 28.0 ma cpu, ram and flash memory at 25 c and 1.8v core 8.0 ma total rx current ( = i radio receiver, mac and baseband, cpu + i ram, and flash memory ) at 25 c, vdd_pads = 3.0v 36.0 ma tx current radio transmitter, mac, and baseband (boost mode) at max. tx power (+ 5dbm typical) 34.0 ma radio transmitter, mac, and baseband at max. tx power (+ 3dbm typical) 28.0 ma at 0dbm typical 24.0 ma at min. tx power (- 32dbm typical) 19.0 ma cpu, ram, and flash memory at 25 c, vdd_pads = 3.0v 8.0 ma total tx current ( = i radio transmitter, mac and baseband, cpu + i ram, and flash memory ) at 25 c and 1.8v core; max. power out 36.0 ma
sn260 electrical characteristics 43/47 13.5 digital i/o specifications ta bl e 1 5 contains the digital i/o specifications for the sn260. the digital i/o power (named vdd_pads) comes from three dedicated pins (pins 13, 19, and 24). the voltage applied to these pins sets the i/o voltage. table 15. digital i/o specifications parameter name min. typ. max. unit voltage supply vdd_pads 2.1 3.6 v input voltage for logic 0 v il 0 0.2 x vdd_pads v input voltage for logic 1 v ih 0.8 x vdd_pads vdd_pads v input current for logic 0 i il ?0.5 a input current for logic 1 i ih 0.5 a input pull-up resistor value r ipu 30 k input pull-down resistor value r ipd 30 k output voltage for logic 0 v ol 0 0.18 x vdd_pads v output voltage for logic 1 v oh 0.82 x vdd_pads vdd_pads v output source current (standard current pad) i ohs 4ma output sink current (standard current pad) i ols 4ma output source current (high current pad: pins 33, 34, and 35) i ohh 8ma output sink current (high current pad: pins 33, 34, and 35) i olh 8ma total output current (for i/o pads) i oh + i ol 40 ma input voltage threshold for osca 0.2 x vdd_core 0.8 x vdd_pads v output voltage level (tx_active) 0. 18 x vdd_core 0.82 x vdd_core v output source current (tx_active) 1 ma
electrical characteristics sn260 44/47 13.6 rf electrical characteristics 13.6.1 receive ta bl e 1 6 lists the key parameters of the integrated ieee 802.15.4 receiver on the sn260. note: receive measurements were collected with ember?s sn260 lattice balun reference design at 2440 mhz and using the emberznet software stack version 3.0.1. the typical number indicates one standard deviation above the mean, measured at room temperature (25 c). the min and max numbers are measured over process corners at room temperature (25 c). table 16. receive characteristics parameter test conditions min. typ. max. unit frequency range 2400 2500 mhz sensitivity (boost mode) 1% per, 20byte packet defined by ieee 802.15.4 -100 -95 dbm sensitivity 1% per, 20byte packet defined by ieee 802.15.4 -99 -94 dbm high-side adjacent channel rejection ieee 802.15.4 signal at -82dbm 35 db low-side adjacent channel rejection ieee 802.15.4 signal at - 82dbm 35 db 2 nd high-side adjacent channel rejection ieee 802.15.4 signal at - 82dbm 40 db 2 nd low-side adjacent channel rejection ieee 802.15.4 signal at - 82dbm 40 db channel rejection for all other channels ieee 802.15.4 signal at - 82dbm 40 db 802.11g rejection centered at + 12mhz or - 13mhz ieee 802.15.4 signal at - 82dbm 35 db maximum input signal level for correct operation (low gain) 0dbm image suppression 30 db co-channel rejection ieee 802.15.4 signal at - 82dbm - 6 dbc relative frequency error (2 x 40 ppm require d by ieee 802.15.4) - 120 + 120 ppm relative timing error (2 x 40 ppm require d by ieee 802.15.4) - 120 + 120 ppm linear rssi range 40 db rssi range -90 -30 db
sn260 electrical characteristics 45/47 13.6.2 transmit ta bl e 1 7 lists the key parameters of the integrated ieee 802.15 .4 transmitter on the sn260. note: transmit measurements were collected with ember?s sn260 lattice balun reference design at 2440 mhz and using the emberznet software stack version 3.0.1. the typical number indicates one standard deviation above the mean, measured at room temperature (25 c). the min and max numbers are measured over process corners at room temperature (25 c). 13.6.3 synthesizer ta bl e 1 8 lists the key parameters of the integrated synthesizer on the sn260. table 17. transmit characteristics parameter test conditions min. typ. max. unit maximum output power (boost mode) at highest power setting 4.5 dbm maximum output power at highest power setting ?0.5 2.5 dbm minimum output power at lowest power setting ?32 dbm error vector magnitude as defined by ieee 802.15.4, which sets a 35% maximum 15 25 % carrier frequency error ?40 + 40 ppm load impedance 200 psd mask relative 3.5 mhz away ?20 db psd mask absolute 3.5 mhz away ?30 dbm table 18. synthesizer characteristics parameter test conditions min. typ. max. unit frequency range 2400 2500 mhz frequency resolution 11.7 khz lock time from off, with correct vco dac setting 100 s relock time channel change or rx/tx turnaround (ieee 802.15.4 defines 192s turnaround time) 100 s phase noise at 100 khz ?71 dbc/hz phase noise at 1 mhz ?91 dbc/hz phase noise at 4 mhz ?103 dbc/hz phase noise at 10 mhz ?111 dbc/hz
revision history sn260 46/47 14 revision history table 19. document revision history date revision changes 11-dec-2006 1 initial release. 03-dec-2007 2 document status promoted fr om preliminary data to datasheet. 17-apr-2008 3 corrected units value in figure 7: spi protocol timing parameters on page 26 . 23-mar-2009 4 added uart gateway protocol section. removed emberznet serial protocol section.
sn260 47/47 please read carefully: information in this document is provided solely in connection with st products. stmicroelectronics nv and its subsidiaries (?st ?) reserve the right to make changes, corrections, modifications or improvements, to this document, and the products and services described he rein at any time, without notice. all st products are sold pursuant to st?s terms and conditions of sale. purchasers are solely responsible for the choice, selection and use of the st products and services described herein, and st as sumes no liability whatsoever relating to the choice, selection or use of the st products and services described herein. no license, express or implied, by estoppel or otherwise, to any intellectual property rights is granted under this document. i f any part of this document refers to any third party products or services it shall not be deemed a license grant by st for the use of such third party products or services, or any intellectual property contained therein or considered as a warranty covering the use in any manner whatsoev er of such third party products or services or any intellectual property contained therein. unless otherwise set forth in st?s terms and conditions of sale st disclaims any express or implied warranty with respect to the use and/or sale of st products including without limitation implied warranties of merchantability, fitness for a parti cular purpose (and their equivalents under the laws of any jurisdiction), or infringement of any patent, copyright or other intellectual property right. unless expressly approved in writing by an authorized st representative, st products are not recommended, authorized or warranted for use in milita ry, air craft, space, life saving, or life sustaining applications, nor in products or systems where failure or malfunction may result in personal injury, death, or severe property or environmental damage. st products which are not specified as "automotive grade" may only be used in automotive applications at user?s own risk. resale of st products with provisions different from the statements and/or technical features set forth in this document shall immediately void any warranty granted by st for the st product or service described herein and shall not create or extend in any manner whatsoev er, any liability of st. st and the st logo are trademarks or registered trademarks of st in various countries. information in this document supersedes and replaces all information previously supplied. the st logo is a registered trademark of stmicroelectronics. all other names are the property of their respective owners. ? 2009 stmicroelectronics - all rights reserved stmicroelectronics group of companies australia - belgium - brazil - canada - china - czech republic - finland - france - germany - hong kong - india - israel - ital y - japan - malaysia - malta - morocco - singapore - spain - sweden - switzerland - united kingdom - united states of america www.st.com

▲Up To Search▲

Price & Availability of SN260Q

	To Download SN260Q Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .